you're going to need to check that all the other kwargs are None

Thanks, I'll change this, but first I need to solve #24329, because right now we rely on Timestamp constructor changing ts.value when called on a localized DST Timestamp (this is why the tests for this PR break currently).

Depending on how digging through the code goes, this PR might also take care of #24329, but I still need a couple days to analyze tz_localize, pd.date_range, and the Timestamp constructor.
Update: a separate PR is needed. Dealing with #24329 in PR #30995, will return here after that gets done.

@jbrockmendel Solved #24329. Now this PR can be reviewed again.

This shortcut, along with the fix to #24329 makes this exception no longer necessary, as a correct value gets returned without an error.
UPDATE: #31155 made the check succeed with dateutil.__version__ >= 2.7.0 . With this shortcut, the exception is not necessary with any version of dateutil. What happened before was that during making a date_range we would call pd.Timestamp twice and this would alter the object in case of a dateutil timezone near a winter/summer DST switch, which would make the test fail. #31155 made sure that the object didn't get altered with an updated version of dateutil and this shortcut eliminates the danger of the Timestamp being altered altogether, because the shortcut simply returns that same object.

I suggest we check for emtpy kwargs similar to the way we check for empty date attributes.

The same as with _date_attributes.

This makes sense. One question since we're focusing on performance: does it make a difference if you write out the verbose and foo is None and bar is None and baz is None...? i have a suspicion that cython doesnt optimize this list comprehension

@jbrockmendel Let's test it then.
The current implementation:

>>> ts = pd.Timestamp("2019-01-01")
>>> timeit.timeit(lambda: pd.Timestamp(ts), number=10000000)
5.860465700000002

And now with this implementation:

        if (isinstance(ts_input, Timestamp) and freq is None and
                tz is None and
                unit is None and
                year is None and
                month is None and
                day is None and
                hour is None and
                minute is None and
                second is None and
                microsecond is None and
                nanosecond is None and
                tzinfo is None):
            return ts_input

>>> ts = pd.Timestamp("2019-01-01")
>>> timeit.timeit(lambda: pd.Timestamp(ts), number=10000000)
4.43885800000001

I've also tested this when we supply other arguments, but the overhead (or early exit from the shortcut if condition) aren't noticeable then, because the non-shortcut Timestamp is so much slower.
I think you are right, and we probably incur the overhead because Cython doesn't explode the list comprehension and instead calls the Python API.
To be honest, the exact reasoning doesn't matter, because I don't think we'll find anything faster than chaining arg is None and checks.

@jbrockmendel This appears the way to go if we need maximum performance.
We do lose a bit of speed (between 10 and 20 percent) because we implement the shortcut after errorchecks and _date_attributes.
Is this fine or should we hoist it after (or before) _date_attributes = [year, month, day, hour, minute, second, microsecond, nanosecond]? I think the current way is tidier, but it's a tradeoff.

I'm not sure all of these extra checks are worth adding to improve perf when passing a Timestamp to a Timestamp constructor - @AlexKirko how often are you expecting that to actually happen?

how often are you expecting that to actually happen?

For internal usage there are a lot of places where we do:

if isinstance(obj, (datetime, np.datetime64)):
    obj = Timestamp(obj)

That's not exactly the usage being checked here, but could benefit in the same way from an optimized no-other-arguments-passed check.

Admittedly, I don't know the library well enough to comment on internal usage, but @jbrockmendel has already done that.

However, what I've done repeatedly in my own projects when on a deadline is take a Dataframe column or a list and just cast the elements into the type I need, trusting that if it already is that class, the performance loss won't be noticeable in the larger program (I do lots of ad-hoc data science modeling). I don't think it's as much of a problem in production-quality code, but a lot of people I work with use pandas to quickly preprocess data for sklearn.

You tend to rely on being able to cut corners when working with a well-supported package, and, currently, calling Timestamp on a Timestamp is more than 10 000 times slower than the proposed shortcut, which can be a nasty shock for someone expecting to just blitz through type conversions during data wrangling.

@WillAyd We could make the code a bit more compact with what was proposed in 4c9eb70, which you can look up above, but this incurs about a 25% performance loss. I believe that if we do the shortcut, might as well add extra two lines. It's a bit grating but the gain is worth it, I think.

can you add a comment to the effect of "we do this verbose thing because cython wont optimize a list comprehension (as of cython 0.29.x)"

@jbrockmendel Added the comment you requested.

@jreback

Added benchmarks for scalar cast and apply. Didn't touch astype, as this PR doesn't change astype performance. Is this what you had in mind?

benchmark.tslibs is intended to only depend on _libs.tslibs, so shouldnt have any Series objects in it. just benchmark the Timestamp contructor here

as long as we're at it, might as well have cases for single-arguments for np.datetime64, pydatetime, and tzaware

@jbrockmendel
Was this what you had in mind? I think we should leave only the scalar transformer for benchmarking this shortcut. Don't see much sense in adding the benchmarks for transforming a Series.

this looks good

perfect, thanks